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associate power of attorney for the undersigned to prosecute the application. Please amend 

the specification and claims in the application as follows. 

Tn the Soecification 

Please kindly make the following amendments to the specification. 

Page 3, para 2 (once amended). A system pemiitting the remote conmiunication with a 

medical device. The system particularly may permit me remote commimication such 
that one or more device experts such as physicians and tnore experienced device users 
may be awaie of the communication and provide guidance for the subsequent 
interpretation and programming of the device. The system may include a medical 
device adapted to be implanted into a patient; a Server Personal Computer (SPC) 
communicating with the medical device, the SPC having means for transmitting data 
across a dispersed data communication pathway (Intertiet); and a client Personal 
Computer (PC) having means for receiving data transmitted across a dispersed 
communication pathway ftom the SPC. In certain configurations the server PC may 
have means for transmitting data across a dispersed data communication pathway 
Ontemet) along a first channel and a second channel; and the client PC may have 
means for Receiving data transmitted across a dispersed communication pathway fiom 
the SPC along a first channel and a second channel. Personal Computer (PC) is a 
registered trademark of International Business Machines Corporation. 



Page 8. para 3 (orice amended). As seen, the system has essentially five primary components. 
Medical dfevice 1 may be of any type which provides therapy to apatientor 
information collection so long as the device has the ability for communication (uplink 
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and downUnk) to an external device, seen here as programmer 2. Medical device 
may. for example only and without Umitation, comprise a Medtronic Kappa 400 
DDDR (Dual paced Ehial sensed Dual response to sensing Rate modulation) 
pacemaker. I>rogrammer 2 may, again, be of any acceptable design which permits 
Unkage to a medical device including the Medlionic 9790 programmer. 

Page 10. para 2 (once amended). In the present invention, the second data sixeam is used for 
transmission the ECG (Electro Cardio Graph), hence, the UDP data consists of only 
two bytes per message - one data point of the ECG waveform aod its ordinal number. 
Apart from ;the ECG waveform, the cardiac therapy device could also send the lEGM. 
some hemodynamic parameter wavefonn such as blood pressure, blood flow, or even 
■ the ultrasoiind measurement waveform. UDP can be also used for transmission of the 
marker channels as well as ofthe various biochemical sensors signals. For example, 
within the context where the medical device is anerve stimulator (similar to the 
Medtronic Itrel series) the device could transmit a BEG or EGG waveform. In fact, a 
nerve stimulator having the capability to measure the tremor intensity would transmit 
the signal representing the tremor intensity thus enabling the DBS (Deep Brain 
Stimulation) output programming according to the tremor intensity. Since digitized 
waveforms have an inherent redundancy, in that the general waves are known as well 
as the possible values of the different parameters, missing data packets or missing 
data may be quickly identified as being actually missing, as opposed to indicating 
very low sensed and reported signal strength, or the data having pecuUar vahies. UDP 
packets afe satisfactory for this purpose because it is not crucially important that 
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every packet arrives. Missing data packets, however, should not tionnaUy h^pen on 
dedicated network link and therefore this event may be used as an additional test of 
the network'link. That is the amount of missing data packets may be used as a 
parameter to indicate to the users the fidelity of the link. Such fideUty may be 
communicated through a pop-up menu or box on one or more of the users screens. 
This box may indicate that the network transmissions are not complete and that data is 
missing. Courses of action may thereafter be recommend, hicluding restarting the 
system, or reissuing the command . It must be understood, however, that other 
protocols for data transfer may also be used, other than only UDP, 

Page 12, para 3 (once amended) FIG. 2A illustrates further details of the possible system 
embodiment. The server 200 is installed in the remote clinic operated by the 
technician 201. In this embodiment, programmer 203 having an ECG interface is a 
separate device and is comiected to server 200. Patient 204 is comiected by the ECG 
cable (not shown) to the interface 203 for the purpose of the ECG recording, while 
programming wand 205 through an electromagnetic coupling enables, as is well know 

the medical device field, the communication with the implanted device (not 
shown). The server 200 is the most complex component of the system, which 
provides real-time data about the patient's state, accepts and executes the operator's 
commands, monitors the system's overall performance and reliability, resolves all 
dubious situations and acts in emergency situations. The server is designed to take 
all IMS responsibility because it is nearest to the patient, and faihut: of any of the 
components between it and the patient are least likely. It may be a standard PC 
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computer, but also a "black box" without special screea and command buttons which 
could confuse the operator 201. A variety of different types of devices may be used 
i to connect server 200 to the Intemet (which usually comprises hubs and routers which 

are not shown) including modem, ISDN or ATM interface 206. A second device is 
provided to connect cUent 208 to the Intemet. A modem 207 is illustrated as 
connecting client 208 to the Intemet (of course other devices such as ISDN or ATM 
interface may also be used.) Advisor 209, being the expert for the particular therapy 
witti the medical device, is the operator ofthe client computer 208. The client 208 
shows to the operator 209 a graphic user interface that visually and functionally 
mimics the GUI ofthe implantable device programmer 203. It displays the ECG 
waveform ofthe patient, and comprises the controls ofthe ECG recording and display 
as well as the implantable device programming commands. 



; Page 15, para 1 (once amended) FIG. 3B is a schematic block diagram ofthe steps 

undertaken for the communication with a medical device using the system ofthe 
present invention disclosed in FIG. 2B. It is assumed for this illustration that the 
programmer and the cUent are a single hardware device. Of couise. this isnotper se 
required and separate and discrete devices may also be used. As seen at 3-1 , the 
server is logged into. Thereafter, the server software application is begun at 3-2, 
whereby server waits for dial-up network connection call. At any time, at 3-3 the 

! 

patient activates his device and the client application starts at 3-4. Patient puts the 
programming wand above the implanted device and cUent identifies medical device 
through uplinking in identified step, step 3-5. Patient connects the ECG cable to bis 
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body starting to record the ECG waveform at 3-6 supplying the cUent with the ECG 
signal at 3-7. ; At 3-8 client makes a call sending the appropriate request to the server 
in onJer to esiabUsfa the dial-up network connection whereby starting to send a real- 
time ECG waveform in UDP packets as well as the patient data. As discussed above, 
this takes place via the Internet using various communication protocols, including 
TCP/IP. THe server identifies the cUent at 3-9 and the real-time ECG waveform is 
continuously displayed at 3-10 within the server GUI together with the all of the 
patient data. CUent sends the device identification at 3-1 1 and server starts the 
software apphcation for the specific device at 3-12. This causes Ihe change Of the 
GUI at 3-13 bringing display of the additional menus and buttons for interrogation 
and prograniming of the specific device. After upUnk, device has automatically 
completed tl^e telemetry measurements at 3-17. Operator of the server points to the 
appropriate button at 3-14 putting an interrogation and telemetry request at 3-15 to the 
cUent through the network which receives and interprets this command at 3-16. As 
seen, diagnostic memory content and telemetry results are prepared at 3-18 for the 
processing in order to make a Java applet at 3-19 and to send it via network. The 
server receiVes and interprets the applet at 3-20 and displays the telemetry and 
diagnostics'screcn at 3-21. This maybe the screen such as the QuickLook™ feature 
of the Vision™ software, the product of the Medtronic, Lac. 

Page 1 6. para 3 (o:^ce amended). FIG. 6 depicts the various types of information transferred 
between cUent. server and device as weU as the protocol used for the transmission. 
As dispussed above, the system preferably uses at least two communication 
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chaimels: the first chaxmel requiring a receipt returned. The second data channel, 

in contrast, does not provide a receipt that the information was properly received. 

As seen, the system preferably uses a non-receipt information protocol for 

information such as the QRS signals (ventricular depolarization) of apacemaker, 

such infomiation is ongoing display information in which the absence of data may 

be readily ascertained as well as not immediately crucial to device operation. 

Other information, such as commands, are transmitted using a protocol in which a 

receipt of acceptance is provided. 

Page 18, para 2 (once amended). FIG. 9 depicts an additional system to tie present system. 
The present system permits communication to be made over dispersed medimns such 
as an intemet. As such it pemuts ready access by a multiple number of clients to a 
single server. Thus, as seen, the system could permit, in addition to client A, depicted 
here as 4 (and which is communicated with and to in the same manner as that 
discussed with regards to FIG. 1), the additional provision of client B 9-2 and cUent C 
9-3. These additional clients may have varying means of access to the server and, 
thus, to the programmability of the device. For example, client B may have access to 
be only an observer while cUent C may be provided to be an observer/cUent with the 
additional' ability to interrogate the device as well as do memory and telemetry read 
out. In this environment, moreover, server 3 plays a more active role. For example, 
as discussed above each client may have various level of access. To permit this, 
server 3 provides differing GUI applets to the differing authorized clients. For 
examplc'only one authorized client would have the possibility to control the 
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prograniming session i.e. program the therapy device and to see the private patient 
! data. Other clients would only have the possibility to observe what is the authorized 

client doing. They could also save the interrogated program and telaraetry data as well 
i as the ECG, lEGM (Intracardiac ElectroGraM) and marker chaimel waveforms in 

their computers for the later recall for the education purpose. 



Page 21, para 1 (once amended). ATM brings completely new possibilities for telemedicine 
and particularly for the implantable devices foUow-up. IP over ATM will be the most 
important variant of tiie infrastructure utilized for the public networic. ATM is a 
connection-onented technology utilizing the Layer 2 cell switching of the Open 
Systems Interconnection protocol that is the hardware based. In contrary to that, IP is 
a connectionless protocol whereby IP networks use software-based Layer 3 packet 
routing. From the practical point of view, the most convenient for teleprogramming 
would be the ATM connection between the client and the server, despite of the fact 
which one ai the two comprises the programmer. It may h^pen that commercial 
interest will rise among the medical institutions and small physicians offices in such a 
manner that they will have multiple tasks and therefore cheap ATM connection for 
teleradiology, telepathology, teleconference, telesurgery and oflaer various 
telemedicine applications. Nevertheless, several IP over ATM protocols are in 
development. Particularly the Internet Engineering Task Force (IETF) has been active 
developing the RFC 1577 being the first true IP over ATM technology called 
Classical IPI (CLIP) and emulating the IP subnetwoik in an ATM infrastructure. One 
or more logical internetworking subnetworics are connected to a backbone subnetwork 
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